Garbage collection is an important feature of modern programming languages that removes the burden of manual memory management from the programmer. Such electronic garbage collection may be classified as either concurrent or stop-the-world. In a stop-the-world garbage collection system, to reclaim memory, all threads are stopped while the garbage collector thread walks all live objects. The process of walking all live threads can take tens of milliseconds, rendering stop-the-world type garbage collection unsuitable for applications having real-time requirements such as video conferencing or telephony. In contrast, concurrent garbage collectors do the work of reclaiming free memory while the other threads in the system continue working. Such concurrent garbage collection systems have reduced “pause” times suitable for use with real-time applications.
Garbage collection systems are further classified as moving or non-moving. Non-moving garbage collection systems do not move objects, resulting in memory fragmentation. Such fragmentation leads to increased allocation overhead, poorer cache locality, and impedes the allocation of large objects in the memory.
A concurrent and moving garbage collection system may create “lost update” issues. With a concurrent and moving garbage collection system, an application thread (mutator) may attempt to write to an object that the garbage collection system is in the process of moving to a new location. If the garbage collection system copies an object's field to a new location and an application thread then attempts to write to the field prior to learning that the object has been moved, the application thread writes to the old location of the object. The garbage collection system will not know the application thread has written to the moved object's old location and will not know to update the new location of the moved object to reflect the update. In such circumstances the update provided to the old location will be “lost” and may result in an error or incorrect execution of the application.
Solutions to the “lost update” problem have been implemented non-transactionally, using software transactional memory, and using hardware transactional memory. The problem with the non-transactional and software transactional memory solutions is that such solutions are inefficient and place a high level of overhead on an application.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.